Agile development of software, firmware, and/or hardware concerns the economy of scope, as opposed to scale, and can be defined as the ability to manage and apply knowledge effectively, to adapt to change, and the capability to quickly respond to market requirements. The term “Agility” may be used to refer to the practice of Agile development.
Generally, Agile development methods, according to the disclosed technology, break product development work into small increments, which may minimize the amount of up-front planning and design required by the development organization. Typically, iterations are short time frames, and each iteration generally involves a cross-functional team working in all applicable capacities (e.g., planning, analysis, design, coding, and testing). At the end of an iteration, a working product is typically demonstrated to the customer. The underlying theory of Agile development is that this iterative process may minimize overall risk and allow the development organization to quickly adapt to changes by increasing the involvement of the customer throughout development and thus allowing changes to be made during development. It should be noted that a completed iteration does not necessarily render a final, market-releasable product. Instead, one of the goals of each iteration is to present a working product with respect to a particular iteration, which is a primary measure of development progress.
Agility may be further broken down into various dimensions: enriching the customer, cooperating to increase competitiveness, organizing to control change and uncertainty, and leveraging the impact of people and information. The speed with which a development organization can respond to customer requests, market dynamics, and emerging technical change may be viewed as a key element of an Agile approach. This includes time to sense relevant events, time to interpret what is happening and assess the consequences for the organization, time to explore options and decide which actions to take, and time to implement the appropriate responses. Organizational capabilities that provide the basis for conducting business and creating change are also considered a prerequisite to achieve Agility.
As it relates to development, Agile is an iterative development methodology based on self-organizing and cross-functional teams. Key concepts include: individuals and their interactions are more important than processes and tools, working software is more important than documentation, customer collaboration is more important than contract negotiation, and responding to change is more important than following a plan.
While these methodologies have become increasingly popular and accepted for managing software development, challenges exist in the adoption and implementation of Agile techniques and for determining what the optimum level of adoption is, especially with respect to certain applications.
For instance, embedded systems provide an especially challenging development environment due to the required parallel management of software, firmware, and hardware development. Embedded systems can be found in a variety of applications, including the Internet of Things. Extreme market demands for innovative products may result in hyper accelerated markets that present added difficulty for the development of software, firmware, and/or hardware. An embedded system typically consists of a combination of software, firmware, and hardware components that must be developed and tested in tandem. Because of the characteristics of embedded systems, making a change to an embedded device (e.g., once several physical products have already rolled off the assembly line) could be a monumental undertaking both technically and financially. In line with these characteristics, Agile methods are often not considered by development organizations for embedded systems development, likely due to a lack of full life cycle support and tools. More specifically, this hesitance may be at least partly attributable to the fact that firmware and hardware development teams tend to be much smaller than their software counterparts and tend to possess a much higher degree of specialization. While many software developers in an organization may possess skills that are easily transferable from one project to another (such as C#, Java, or .NET programming), their firmware counterparts typically do not share the same level of transferability. Firmware professionals often have very focused knowledge of the embedded systems stacks (e.g., home area networking, RF network communication, or metering metrology) that inhibits them from being easily interchangeable. Embedded systems are often mission-critical systems with corresponding high consequences of failure. As a result, organizations developing such systems tend to be less comfortable with the higher rates of change that often accompany the iterative Agile development as compared to organizations developing only software.
Regarding the appropriate level of adoption of Agile methodologies, some applications may benefit from the combination and mixing of certain aspects of Agile with other development methodologies. For instance, certain development efforts may benefit from mixing some aspects of Agile with some aspects of the waterfall methodology. Whereas Agile methods present an iterative development process in which, for instance, testing occurs simultaneously with programming, the waterfall methodology is a sequential process that has separate programming and testing phases, for instance. For example, in a typical waterfall methodology, the testing phase does not begin until the programming phase has been completed. That is, a subsequent stage of development does not begin until a previous stage has been completed. Such a transfer of development focus is sometimes referred to as a stage gate. Currently, there is no definition or criterion available to determine the appropriate mix of Agile, waterfall, and other development methodologies for particular development efforts.
Current practices are unable to determine the value of a particular product development effort in relation to a specific business or development team's competitive position in the marketplace. That is, there does not currently exist a way to evaluate the adoption of Agile principles against quality and customer responsiveness. Thus, a business or development team cannot evaluate whether a product development effort is creating the most competitive result possible in its respective market.